Computer systems and related technology affect many aspects of society. Indeed, the computer system's ability to process information has transformed the way we live and work. Computer systems now commonly perform a host of tasks (e.g., word processing, scheduling, database management, etc.) that prior to the advent of computer systems were performed manually. More recently, computer systems have been coupled to one another to form computer networks over which the computer systems can communicate electronically to share data. Web services have been a driving force in advancing such communications between computer systems and are turning the building and use of software inside-out.
Web services let applications share data, and—more powerfully—invoke capabilities from other applications without regard to how those applications were built, what operating system or platform they run on, and what devices are used to access them. Web services may be invoked over the Internet by means of industry-standard protocols including SOAP (Simple Open Access Protocol), XML (extensible Markup Language), UDDI (Universal Description Discovery Integration), WSDL (Web Service Description Language), etc. Although web services remain independent of each other, they can loosely link themselves into a collaborating group that performs a particular task.
Often, electronic communication on a web service network includes a client computer system (hereafter referred to as a “client”) requesting access to a network service (e.g., web services) at a server computer system (hereinafter referred to as a “server,” “service,” or “web service”). Accordingly, the client sends a request to the service for particular access to its system resources, wherein the service replies with a response message providing the desired information. Of course, other messaging patterns between client and service may be available and include simple singleton messages as well as more sophisticated multi-message exchanges like, e.g., notifications, solicit-response, pub-sub patterns, polling, kick-push, queuing, and others. In addition, there may be other procedures needed for accessing the service resources, such as authentication and validation mechanisms.
Regardless of the type of message patterns and/or procedures used to access a service, web services provide interoperability in a platform agnostic way because both clients and services agree on a basic contract. Represented by a mixture of machine-readable and human languages (i.e., XML), such contracts define, among other things, the operations—units of functionality—offered by the web service and/or the format of the messages passed to and/or returned by each operation when invoked. Network Protocol Description Languages (e.g., WSDL) provide an overall wrapper or specification for describing web service contracts in a common or standard language. Such specifications make it easy for developers and developer tools to create and interpret contracts; and also have extensive tooling suites, which in large part accounts for their popularity.
Typically, most web service contracts define SOAP as the protocol of choice for sending messages between a client and service via the Internet. SOAP is an XML based protocol and forms the foundation layer of a web service stack, providing a basic messaging framework that more abstract layers can build on. A SOAP message contains several elements including: a required root element known as an envelope that identifies the XML document as a SOAP message as well as the schema(s) used therein; an optional header element, which includes processing and application specific information (e.g., authentication, date and time created, message type, message identity, and other information) about the SOAP message; and a required body element that contains call and response information, if any. An optional fault element provides information about errors that occurred while processing the message. If a fault element is present, it typically appears as a child element of the body.
One of the key strengths of SOAP is the ability to encapsulate XML data within a SOAP message. This gives SOAP the flexibility to contain data from any XML schema, which is quite empowering. Schemas provide rigorous rules for ensuring that documents can be handled automatically by the various programs for which the XML data is passed. In other words, an XML schema is a description of a type of XML document, typically expressed in terms of constraints on the structure and content of documents of that type, above and beyond the basic syntax constraints imposed by XML itself. Accordingly, when using SOAP as a network protocol layer, the XML which is transmitted must conform to the XML schema requirements. That is, a payload formatted in the XML must be scoped to a valid XML namespace and the XML content must schematically conform to the schema represented by that namespace.
In short (based on, e.g., the type of message and/or operation used—for example, a “request” message for a “put” operation, a “response” message to a “get” operation, etc.), the message must not violate the constraints of the associated XML schema. For example, suppose an XML schema defined A, B, and C as minOccurs=“1”—as shown in the following pseudo-code for a hypothetical XML schema:
<xs:element name=“MyObject”><xs:complexType><xs:sequence><xs:element name=“A” type=“xs:int” minOccurs=“1”maxOccurs=“1” /><xs:element name=“B” type=“xs:int” minOccurs=“1”maxOccurs=“1” /><xs:element name=“C” type=“xs:int” minOccurs=“1”maxOccurs=“1” />. . .A SOAP message that included one of these elements must include values for all three—since the schema mandates that all three be present. Otherwise, the SOAP message when processed for validation would be considered “illegal” and should be faulted.
At the same time, mechanisms are emerging that allow users to “filter” XML using query engines so that unnecessary content is not returned to the caller. A filter engine may also be called an “inverse query engine,” where (unlike a database wherein an input query is tried against a collection of data records) the engine tries an input against a collection of queries. Each query includes one or more conditions, criteria, or rules that must be satisfied by an input for the query to evaluate to true against the input. For example, an XPath filter engine is a type of inverse query engine in which the filters are defined using the XPath language. The message bus filter engine matches filters against XML to evaluate which filters return true, and which return false. The input for the various filters (e.g., XPath expressions) may be defined using various path expressions, operators, and functions as defined by the particular language used.
Although inverse query filters with their extensive tools allow for flexible and powerful searching mechanisms, there is currently no way to use them for modifying XML documents. In addition, these filter engines are often incapable of being used in a SOAP environment since the resulting output yielded by executing or processing such query expressions often violate the qualified schemas for the SOAP messages. Nevertheless, with the increased popularity of filtering and node-selection, there have been many attempts to create mechanisms by which such inverse query filters can be used over SOAP without violating the schema rules required.
One such solution suggests defining elements as “optional” within the schema. Although this approach may appear reasonable, it is often impractical for most real world situations. More specifically, schemas are often designed by the industry or service for which they or used or by some other standards body. Accordingly, the schemas are typically designed outside the SOAP environment for specific use within the boundaries considered most useful to that particular service. For example, a book seller may consider that consumers most often find helpful the title, author, ISBN, publisher, and price when search for a particular book. Accordingly, the seller ties these elements together in the schema since having any one of these elements as optional would be of little use to targeted consumers. Due to cost considerations for defining new schemas, when a service is designed to conform to SOAP protocols developers just borrow the schemas previously defined by the industry. As such, the SOAP messages will also be required to include all of the elements defined by the previously created schema, thus not allowing for full support of inverse query filtering.
Another suggested option has been to define different schemas for all possible combinations of resulting elements. Such an approach, however, not only suffers from the same inherent problems identified above, but is even more impractical in implementation. For example, if a service has even a relatively small number of say four elements, then at least twelve different schemas must be written to cover all possible combinations of the elements. Accordingly, a service with a relatively large number of elements would need hundreds, thousands, or even hundreds of thousands of schemas to describe the needed selections, which is economically and practically unfeasible.